Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New resource and data source: azurerm_automation_variable_object #22644

Merged
merged 6 commits into from
Aug 3, 2023

Conversation

oWretch
Copy link
Contributor

@oWretch oWretch commented Jul 24, 2023

Add support for object-type variables for Automation Accounts. They cannot be created in the Azure Portal, only via API. They can be viewed in the Azure Portal.

Created as a non-typed resource to match the current variable resource types, and continue to share the parsing code. Also using resource_group_name and automation_account_name instead of automation_account_id to match with the current variable resources.

Copy link
Member

@catriona-m catriona-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @oWretch this is looking pretty good so far, just left a couple of minor comments inline. Also, it would be good if we could deserialize the json in the create and serialize in the read, similar to this resource. Thanks!

internal/services/automation/helper/automation_variable.go Outdated Show resolved Hide resolved
website/docs/r/automation_variable_object.html.markdown Outdated Show resolved Hide resolved
Co-authored-by: catriona-m <[email protected]>
@oWretch
Copy link
Contributor Author

oWretch commented Aug 2, 2023

Hi @catriona-m. I'd love to handle the serialisation within the CRUD functions, but I can't see how to achieve this. When I look at the schema type definitions, I can only use standard Go types, which therefore has all the limitations that come with them. The closest option is to use a TypeMap, but that requires all object values to be of the same type. This works until we want to use nested objects, such as

  value = {
    name    = "Name"
    boolean = true
    num     = 3
    object = {
      name   = "Arthur Dent"
      number = 42
    }
  }

as this causes a panic as object can't be converted to a string. For most other properties, we know what the correct structure of the object will be and so can define the schema in advance. However, these variables will not have a consistent schema that the provider can know about in advance, which is why I resorted to making the user do the serialisation / deserialisation.

Copy link
Member

@catriona-m catriona-m left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @oWretch LGTM!

@catriona-m catriona-m merged commit 18edf39 into hashicorp:main Aug 3, 2023
@github-actions github-actions bot added this to the v3.68.0 milestone Aug 3, 2023
catriona-m added a commit that referenced this pull request Aug 3, 2023
@oWretch oWretch deleted the f/aa-var-object branch March 12, 2024 01:47
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants